-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SDBELGA-759] Feature: Sync Event metadata to Planning & Coverages #1892
Conversation
@petrjasek The code is ready to be reviewed. I have placed this PR in draft state while I add tests |
Embedded/Sync wasn't working once above bug was fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, what's your take on using dataclasses vs typed dicts, should we use both, only one, or have some kind of guidelines?
I don't mind the use of dataclasses, as it provides:
On the other hand, dataclasses should never be used with data that will be used in a:
This is because the data would have to be serialised, which means converting it to a dict first, in which case a dict should be used. Thoughts @petrjasek? |
makes sense |
…uperdesk#1892) * Config: Add new config for Event to Planning sync * ui: Send `embedded_planning` from front-end * api: Improve Planning ContentProfiles module and types * api: Process `embedded_planning` and sync metadata * fix(ui): Failed to get lock for recurring series * fix(ui): Improve EmbeddedCoverageForm UI * fix(ui): Event to Planning translations copies fields multiple times * fix(e2e): Use chrome in CI to run tests * Add behave tests for embedded planning * Add behave tests for multilingual embedded planning * Add CVs to behave test * fix: Coverage Planning updated when processing Assignment details Embedded/Sync wasn't working once above bug was fixed * Add behave tests for event metadata sync
Also moves the EmbeddedPlanning from a front-end feature to be a back-end feature (so that metadata sync and associated planning can be handled with the 1 request, and the 1 DB change).